Skip to content

Fix assert 0xb7b#25735

Merged
markfields merged 7 commits intomicrosoft:mainfrom
markfields:fix-0xb7b
Oct 23, 2025
Merged

Fix assert 0xb7b#25735
markfields merged 7 commits intomicrosoft:mainfrom
markfields:fix-0xb7b

Conversation

@markfields
Copy link
Member

@markfields markfields commented Oct 22, 2025

Description

Fixes AB#48146

There's a corner case where processing incoming ops (join/leave ops in particular) can trigger a connection state transition which can trigger a flush (but there are no changes to flush), and assert 0xb7b fires - it asserts that we should never flush while processing incoming ops. This protects against reentrancy, which is not an issue in this case.

The fix is to only assert if we have something to flush.

@markfields markfields requested review from Copilot and kian-thompson and removed request for Copilot October 22, 2025 22:10
@github-actions github-actions bot added area: runtime Runtime related issues base: main PRs targeted against main branch labels Oct 22, 2025
Copilot AI review requested due to automatic review settings October 23, 2025 00:05
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes a bug where assert 0xb7b incorrectly fires when flushing empty batches during reentrant operations. The assert was designed to prevent reentrancy issues when flushing operations, but it triggered even when there were no operations to flush, which is safe.

Key Changes:

  • Modified the assert to only check for reentrancy when there are actual batches to flush
  • Removed the intermediate flushAll method and consolidated logic into flush
  • Added test coverage for both empty and non-empty batch flush scenarios during reentrant state

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
packages/runtime/container-runtime/src/opLifecycle/outbox.ts Moved reentrancy assertion to only trigger when batches are non-empty, consolidated flushAll into flush, and added assertion with string message in flushResubmittedBatch
packages/runtime/container-runtime/src/test/opLifecycle/outbox.spec.ts Added two test cases to verify the fix: one confirming no assertion with empty batches during reentrancy, and another confirming assertion still fires with non-empty batches

Comment on lines +409 to +412
assert(
!this.isContextReentrant(),
"Flushing must not happen while incoming changes are being processed",
);
Copy link

Copilot AI Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New assert added with string literal message instead of hex code. Per coding guidelines (CodingGuidelineID: 1000000), asserts from @fluidframework/core-utils should use string literals for error messages, not hex codes. This is correctly implemented here.

Copilot generated this review using guidance from repository custom instructions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we really need to remove this copilot instruction. it is always wrong

@markfields markfields enabled auto-merge (squash) October 23, 2025 17:08
@markfields markfields disabled auto-merge October 23, 2025 17:12
Previous fix opened up a possible regression under `maybeFlushPartialBatch`
@markfields markfields enabled auto-merge (squash) October 23, 2025 17:59
@markfields markfields merged commit ba8d782 into microsoft:main Oct 23, 2025
33 checks passed
@markfields markfields deleted the fix-0xb7b branch October 24, 2025 17:17
anthony-murphy-agent pushed a commit to anthony-murphy-agent/FluidFramework that referenced this pull request Jan 14, 2026
There's a corner case where processing incoming ops (join/leave ops in
particular) can trigger a connection state transition which can trigger
a flush (but there are no changes to flush), and assert 0xb7b fires - it
asserts that we should never flush while processing incoming ops. This
protects against reentrancy, which is not an issue in this case.

The fix is to only assert if we have something to flush.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: runtime Runtime related issues base: main PRs targeted against main branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants